Summary

Treat slow_down as a retriable error in the GitHub device-flow token polling loop, per RFC 8628 §3.5.

Problem

When GitHub's device-flow token endpoint returns slow_down, the publisher exits with a fatal error:

Error: login failed: error polling for token: token request failed: slow_down

The login session is unrecoverable — the user must re-run the command and hope to authorize before any slow_down is emitted again.

Root Cause

In pollForToken, only authorization_pending is treated as retriable. slow_down falls into the catch-all error branch and aborts:

if tokenResp.Error == "authorization_pending" {
    time.Sleep(time.Duration(interval) * time.Second)
    continue
}
if tokenResp.Error != "" {
    return "", fmt.Errorf("token request failed: %s", tokenResp.Error)
}

Fix

Treat slow_down the same as authorization_pending but with the required interval increase (+5 seconds):

if tokenResp.Error == "authorization_pending" || tokenResp.Error == "slow_down" {
    if tokenResp.Error == "slow_down" {
        interval += 5
    }
    time.Sleep(time.Duration(interval) * time.Second)
    continue
}

Testing

The existing test infrastructure doesn't directly test pollForToken (unexported method, external test package). The fix is minimal (4 lines changed) and follows the exact pattern specified in RFC 8628 §3.5. Can verify manually:

1. Run mcp-publisher login github
2. Open the device URL but delay authorization past the initial polling window
3. Observe that instead of failing, the publisher retries with increased intervals

Related

• Closes mcp-publisher: device-flow login treats GitHub slow_down as fatal instead of backing off #1289
• Related to metrics: stop counting client-cancelled requests as server errors #1255 (metrics-side fix for cancelled requests)